Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-221.txt

Text File | 1994-12-08 | 40.4 KB | 992 lines | [TEXT/R*ch]

C.S.M.P. Digest             Fri, 04 Dec 92       Volume 1 : Issue 221

Today's Topics:

    Custom MDEF/Submenu woes..
    Human Interface P's And Q's
    Quickdraw crashes with simple MoveTo and LineTo
    Copyright or look-and-feel of arcade games
    How do I change the system font?



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  You can post articles to any newsgroup by
mailing your article to [e-mail].  So, to post an
article to comp.sys.mac.programmer, you mail it to
[e-mail].  Note the '-' instead of '.'
in the newsgroup name.

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: Randy DeRuiter
Subject: Custom MDEF/Submenu woes..
Date: 1 Nov 92 18:58:30 GMT
Organization: TheNews


 Thanks for all the help I've received on writing a custom MDEF, especially the
help from Ramon Felciano.  I still have a nagging question which I hope to
resolve:

Is there any way to control the popup location of an attached submenu?  I've
found that if you use a nonstandard item height in your menu ( anything other
than 16 pixels high ) attached submenus do not pop up consistently.  The menu
manager (or MBDF, I'm not sure what's in control here) clearly looks at the
current mouse location when popping up the submenu, and my guess is that it
does some simple integer arithmetic assuming an itemheight of 16 to get the
best popup location.  To my surprise, the mPopUpmsg defined in IM V is not used
for this process, so I don't have an easy way to adjust things with my custom
MDEF.  Any ideas?

Please respond directly if this is not worthy of net discussion.

Thanks,

Randy DeRuiter   [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 2 Nov 92 03:12:45 GMT
Organization: Taligent

In article <[e-mail]>, Randy DeRuiter wrote:
>
> Is there any way to control the popup location of an attached submenu?  I've
> found that if you use a nonstandard item height in your menu ( anything other
> than 16 pixels high ) attached submenus do not pop up consistently.  The menu
> manager (or MBDF, I'm not sure what's in control here) clearly looks at the
> current mouse location when popping up the submenu, and my guess is that it
> does some simple integer arithmetic assuming an itemheight of 16 to get the
> best popup location.  To my surprise, the mPopUpmsg defined in IM V is not used
> for this process, so I don't have an easy way to adjust things with my custom
> MDEF.  Any ideas?

I'm not sure if there is a good solution for you. I recently gave the
standard MBDF a good examination, and discovered that the code that
calculates the various menu item line heights (either 16 or 32) is
duplicated in the standard MDEF and MBDF. This means that if you change the
line heights in your MDEF, the MBDF still assumes normal line heights. This
is bad since it is the MBDF that determines where to position the
hierarchical.

The cleanest and hardest solution would be to re-write the standard MBDF. A
trickier solution, if you have MPW, is to use the information in Private.a
(search for "mbCustomStorage" to get to the private data structures used by
the MBDF). The handle to this private information is stored in the
low-memory location MBSaveLoc. This information includes the calculated
rectangles for all menus on the screen. Perhaps you can sneak in at some
time and tweak them to what you need.

- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

From: [e-mail] (P. Hawthorne)
Subject: Human Interface P's And Q's
Date: 2 Nov 92 11:02:15 GMT
Organization: Reed College, Portland OR


    The new Finder has changed the meaning of the zoomed in state. When
you zoom in, the window zooms to a size just large enough to show the
contents without overflowing the screen. Should new applications adopt
the window zooming conventions of the Finder for document windows?

    As a rule, when the user chooses a command from a menu that brings up
a modal dialog, the menu stays inverted until the dialog is dismissed.
However, that practice seems to be on the way out. Should new
applications uninvert menus once a dialog has come up? If so, should this
be done for the standard file and print dialogs as well?

    Is a standard way of telling the user how much temporary memory is
being consumed by the application?

    A good many of the new control panels from Apple use Geneva for
things that would once only have been done with Chicago. Should the rest
of us ditch Chicago for dialogs or is this just for control panels?

    On a related note, many applications have grouped dialog items within
dark rounded corner boxes. Apple seems to be enclosing groups of items
within boxes, some dimmed and some heavy. In some layouts, groups are
separated with dimmed lines. Is this the Party line?

    Is the way that the new Finder displays folder windows in list form
the official look and feel for outline data?

    Should programmers specifically try to harmonize their their menu
bars so that only the last couple of menus change titles when switching
between the Finder and the app, so as to make the session appear
seamless? Or would that just be daffy?

    Theus ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 2 Nov 92 11:27:22 GMT
Organization: Kalamazoo College

[e-mail] (P. Hawthorne) writes:
>
>    The new Finder has changed the meaning of the zoomed in state. When
>you zoom in, the window zooms to a size just large enough to show the
>contents without overflowing the screen. Should new applications adopt
>the window zooming conventions of the Finder for document windows?

This is the Finder being polite, not the Finder laying down gospel.  It
makes sense for the Finder because it frequently has many windows open,
and things frequently get dragged in, out, and between them.  Do what
makes sense for your documents.

>    As a rule, when the user chooses a command from a menu that brings up
>a modal dialog, the menu stays inverted until the dialog is dismissed.
>However, that practice seems to be on the way out. Should new
>applications uninvert menus once a dialog has come up? If so, should this
>be done for the standard file and print dialogs as well?

I would say:  if the Edit menu is available, yes;  otherwise no.  If you
don't agree with me:  that's OK, I probably won't even notice.

>    Is [there] a standard way of telling the user how much temporary memory
>is being consumed by the application?

OK, here's my suggestion for a standard.  Put a menu item somewhere
called "Non-Program Memory";  when selected, it checks itself and puts
up a floating window that says "Non-program memory in use:  123K".
(Is there an official name for it?  "Multifinder memory" is right out,
and "temporary memory" is a very misleading name, now.)  Whenever the
program allocates temp memory, and the window is not already visible,
and there was no temp mem allocated before, make the window visible.

A help balloon would of course explain what the thing was.

>    A good many of the new control panels from Apple use Geneva for
>things that would once only have been done with Chicago. Should the rest
>of us ditch Chicago for dialogs or is this just for control panels?

Many of the rest of us already have.  The rest of the rest of us are
free to do whatever makes sense for the interface in question.  In
deference to my bifocal-wearing friends who will soon purchase a
Classic II, I intend to use Chicago whenever possible.  (Going back and
forth between bifocal and normal lenses gives you a stiff neck, I'm
told.)
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "I don't think we should have to have them wandering the streets
  frightening women and people."                            - Pat Buchanan

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 2 Nov 92 18:37:16 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (P. Hawthorne)
wrote:
>
>     The new Finder has changed the meaning of the zoomed in state. When
> you zoom in, the window zooms to a size just large enough to show the
> contents without overflowing the screen. Should new applications adopt

I think the guideline has always been to zoom the window to the largest
size that makes sense, rather than just zooming to the size of the screen.
If your document has a limit in one or both directions, then you shouldn't
zoom (much) beyond that limit.

>     As a rule, when the user chooses a command from a menu that brings up
> a modal dialog, the menu stays inverted until the dialog is dismissed.
> However, that practice seems to be on the way out. Should new

You probable should uninvert the menu.  In System 7, the user should be
able to toggle the state of Balloon Help, and it would be nice to implement
the edit menu.

> things that would once only have been done with Chicago. Should the rest
> of us ditch Chicago for dialogs or is this just for control panels?

Chicago is supposed to be the font the system uses to "tell" things to the
user.  Geneval might be used in control panels just be cause of the size
contraints.  Chicago also has the property that it can be dimmed using a
gray pattern and still be readable.

>     Should programmers specifically try to harmonize their their menu
> bars so that only the last couple of menus change titles when switching

The 1st 3 menus should be the same (most of the time); but in general, I
would do what makes the most sense for your app.

Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Leonard Rosenthol)
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Date: Mon, 2 Nov 1992 18:46:34 GMT

Here is my two cents on these questions...

In article <[e-mail]> [e-mail] (P. Hawthorne) writes:
>    The new Finder has changed the meaning of the zoomed in state. When
>you zoom in, the window zooms to a size just large enough to show the
>contents without overflowing the screen. Should new applications adopt
>the window zooming conventions of the Finder for document windows?
>
    YES!  This is described in a Human Interface Note (#7 - Who's Zooming
Who).

>    As a rule, when the user chooses a command from a menu that brings up
>a modal dialog, the menu stays inverted until the dialog is dismissed.
>However, that practice seems to be on the way out. Should new
>applications uninvert menus once a dialog has come up? If so, should this
>be done for the standard file and print dialogs as well?
>
    I would say to uninvert the menu before getting to the dialog. The
reason being that under System 7 the menu bar is active so as to allow
the user to cut/copy/paste in edit fields.  You would not want an inverted
menu in this case.

>    Is a standard way of telling the user how much temporary memory is
>being consumed by the application?
>
    No.  I am not sure that this would be appropriate either...

>    A good many of the new control panels from Apple use Geneva for
>things that would once only have been done with Chicago. Should the rest
>of us ditch Chicago for dialogs or is this just for control panels?
>
    Actually, you should use "applicationFont" as returned from the
GetAppFont() call.  This will give you improved international compatibility.

>    On a related note, many applications have grouped dialog items within
>dark rounded corner boxes. Apple seems to be enclosing groups of items
>within boxes, some dimmed and some heavy. In some layouts, groups are
>separated with dimmed lines. Is this the Party line?
>
    I don't believe that there is any "party line" on this one.  I like
to use either dimmed/dashed boxes or dimmed/dashed lines to separate groups
of items.  This makes a dialog look nicely layed out without overwhelming it
with solid lines & shadowed boxes.

>    Is the way that the new Finder displays folder windows in list form
>the official look and feel for outline data?
>
    I don't think there is any official word here, but it does look
nice and many application vendors have adopted it for their own apps.

>    Should programmers specifically try to harmonize their their menu
>bars so that only the last couple of menus change titles when switching
>between the Finder and the app, so as to make the session appear
>seamless? Or would that just be daffy?
>
    Your menus - do what you want with them (within reason ;).

- --
- -----------------------------------------------------------------------------
Leonard Rosenthol            Internet:     [e-mail]
Director of Advanced Technology        AppleLink:    MACgician
Aladdin Systems, Inc.            GEnie:        MACgician


+++++++++++++++++++++++++++

From: [e-mail] (Sho Kuwamoto)
Date: 2 Nov 92 19:37:25 GMT
Organization: Purdue University Physics Department

[e-mail] (Larry Rosenstein) writes:
>In article <[e-mail]>, [e-mail] (P. Hawthorne)
>wrote:
>>
>>     The new Finder has changed the meaning of the zoomed in state. [...]
>
>I think the guideline has always been to zoom the window to the largest
>size that makes sense, rather than just zooming to the size of the screen.

IM VI 2-23 gives the Apple party line, which says:
  A click in the zoom box toggles a window between two
  states, the user state and the standard state... a
  window's standard state definition is described as
  generally the full screen, or close to it...

  But Macintosh monitors now come in all shapes, sizes, and
  configurations, so applications should never simply assume
  that the standard state should be as large as the screen...

The section goes on to describe the new rules for zooming
windows.  I've written a TCL class to do proper window
zooming, and it takes a couple of pages of code to get all
the nit-picky details right.  You have to check to see which
monitor contains the largest portion of the window, figure
out if the desired standard state will fit on the monitor,
etc., etc.  *sigh*

>>     As a rule, when the user chooses a command from a menu that brings up
>> a modal dialog, the menu stays inverted until the dialog is dismissed.
>> However, that practice seems to be on the way out. [...]
>
>You probable should uninvert the menu.  In System 7, the user should be
>able to toggle the state of Balloon Help, and it would be nice to implement
>the edit menu.

Agreed.  However, I'd like to add one point.  You *should*
use movable modal dialog boxes, and you *should* allow the
user to access the ballon help and application menus (as
well as the edit menu?) but if you aren't going to allow the
user to make menu selections, you should leave the menu
inverted.

- -Sho
- --
[e-mail]

---------------------------

From: [e-mail] (Juri Munkki)
Subject: Quickdraw crashes with simple MoveTo and LineTo
Date: 31 Oct 92 09:41:31 GMT
Organization: Helsinki University of Technology

I'm writing this 3D animation program and in the process of testing the
transformation routines, I decided to use QuickDraw instead of my own
line drawing routines, because I figured it would be one less thing to
test...

If I moved the object really close, the machine would crash. After an
hour or two of looking for bad handles and such, I narrowed the crashing
problem down to the folloing program:

void    main()
{
    Rect    myRect={40,20,200,600};

    InitGraf(&thePort);
    InitCursor();
    InitFonts();
    InitWindows();
    InitMenus();
    TEInit();
    InitDialogs(0L);
    InitCursor();
    MaxApplZone();

    SetPort(NewWindow(0,&myRect,"\pTesting",TRUE,0,(WindowPtr)-1,FALSE,0));

    MoveTo(98,6674);
    LineTo(37,-29103);
}

When it reaches the LineTo, it crashes. I seem to remember something about
QuickDraw not performing well on tall vertical lines, but IMO, it shouldn't
crash with heap/stack collision.

I'm using a PB140 8/40 with System 7.01* with a number of system extensions.
I'm including a binary so that you can check if your system crashes as well.

- --
  Juri Munkki                           Windsurf: fast sailing
 [e-mail]                          Macintosh: fast software

(This file must be converted with BinHex 4.0)

- --
  Juri Munkki                           Windsurf: fast sailing
 [e-mail]                          Macintosh: fast software

+++++++++++++++++++++++++++

From: [e-mail] (Eric Schlegel)
Date: 2 Nov 92 16:39:58 GMT
Organization: Microsoft Corporation

In article <[e-mail]> [e-mail] (Juri Munkki) writes:
>If I moved the object really close, the machine would crash. After an
>hour or two of looking for bad handles and such, I narrowed the crashing
>problem down to the folloing program:
>
>void    main()
>{
>    Rect    myRect={40,20,200,600};
>    <...>
>    SetPort(NewWindow(0,&myRect,"\pTesting",TRUE,0,(WindowPtr)-1,FALSE,0));
>
>    MoveTo(98,6674);
>    LineTo(37,-29103);
>}
>
>When it reaches the LineTo, it crashes. I seem to remember something about
>QuickDraw not performing well on tall vertical lines, but IMO, it shouldn't
>crash with heap/stack collision.
>
>I'm using a PB140 8/40 with System 7.01* with a number of system extensions.

You're not imagining things. From the Basic QD Q&As Tech Note, Sept. 92:

Macintosh QuickDraw LineTo bug and workaround
Written:    4/23/92
Last reviewed:    7/13/92

Our zooming function crashes into flames when we pass valid
coordinate values to LineTo, as in the following example:

    SetPort(myPort);
    MoveTo(154,31619);
    LineTo(74, -31742); (* You are dead! *)

What can we do to avoid LineTo crashes like this?
___

The QuickDraw Engineering group is aware of the problem you
described. The bug probably is going to be fixed in the next
release that includes bug fixes. Given that waiting for a
system solution may demand more patience than is reasonable,
you may want to consider including in your software some form
of workaround that will prevent your users from crashing every
time an operation takes the software to the limits of QuickDraw.

One way to approach this problem is to replace the lineProc
bottleneck. All you need to do is to check the distance between
the current pen position and the lineUs end, and when the
distance becomes too big (letUs say more than 32000) your
procedure will call StdLine a couple of times, splitting the
operation in two.

Replacing the bottlenecks is a very straightforward operation
(which you are probably already using) and in most of the
cases will only result in another level of indirection into
StdLine but that will prevent your program from calling
QuickDraw with parameters that are guaranteed to cause crashes.

- -eric
- ------
My opinions, not Microsoft's.

---------------------------

From: [e-mail] (Michael A. Kelly)
Subject: Copyright or look-and-feel of arcade games
Organization: University of Oregon Computer and Information Sciences Dept.
Date: Fri, 30 Oct 1992 03:49:37 GMT

In article <[e-mail]> [e-mail] (Tim Smith) writes:
>[e-mail] (Michael A. Kelly) writes:
>
>So you can't just say what you have done is "like the difference" between
>Asteriods and Blasteroids.  Copyright protects expression of ideas, rather
>than ideas themselves.  This means that if something is required to express
>an idea, copyright can't protect it.  In particular, copyright can't
>protect the idea of a "shoot rocks in space" game.  The court decided
>that any "shoot rocks in space" game would include Asteroids, and so
>there could be no copyright protection.
>
>On the other hand, "run around a maze avoiding enemies" is a broader
>idea.  There is room for more variation in how that idea is expressed,
>and K. C. Munchkin was too close to PAC-MAN.
>
>Note the result: a near exact clone of Asteroids was OK, but something that
>had several differences from PAC-MAN wasn't OK.  I don't think you will be
>able to get a good answer in your case without divulging details of your
>game.

OK.  The specific part of our game that we're worried about is:

There is an enemy base/fortress/castle (hint hint)/mother ship which is
surrounded by three concentric roughly circular (regular n-sided polygons)
rings/shields.  The rings spin, with the outer and inner rings spinning the
same direction and the middle ring spinning the opposite direction.  The
good guy has to shoot out segments of the rings so that he has a clear
shot at the enemy base when the holes in each ring line up.  The enemy base
can shoot back, also only when the holes in the rings line up.  The base
shoots huge plasma balls like in the first Star Trek movie.

That is what is the same in both the original game and our game.  Here are
some differences:

In the original game, the base & rings were static in the center of the
screen, and the good guy flew his ship around the base, with his flight
wrapping around when he flew off the screen.  In our game, the base stays
in one spot in the world/galaxy, but the galaxy is much bigger than the
screen, so the base could be anywhere on the screen or not on the screen
at all.  Here's one important difference between the two: there is no
notion of the good guy's flight wrapping around on the screen.  The wrapping
was very important in the original game; the enemy base could only shoot
in the direction it was pointing, so the good guy could sit close to the edge
of the screen and fire away from the castle (oops, I mean base), hitting
it from behind, and then thrust forward a bit to the other side of the
screen when the base was aiming at the ship, thus avoiding attack from the
base while whaling on it.  There is no way to do that in our game.

There are no bad guys in the original game (I think, although my partner
thinks that there was).  There are quite a few in our game, with lots of
variation in strength and strategy, plus 'yummies' and 'space garbage' and
asteroids and such floating about in space.  And the good guy's ship is
a lot more complicated than the original.

We've basically taken a simple ten year old video game and extended it
tremendously.  I consider the original game inspiration, but others may
consider it more than that.  I don't want to get sued.  But I don't want
to cause myself any unnecessary legal hassles either.  If it isn't possible
for the makers of the original game to win a lawsuit against us, I'd
rather not go out of my way to bring the game to their attention.

So it sounds like our game vs. the original would probably go the way of
K.C. Munchkin vs. PacMan.  What do you think?

BTW, what happens if that company isn't around any more?

Thanks for your help,

Mike.
- --
_____________________________________________________________________________
Michael A. Kelly                                               Senior Partner
[e-mail]                                      High Risk Ventures
_____________________________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Neil A Haldar)
Date: 30 Oct 92 15:12:27 GMT
Organization: The Ohio State University

Okay... here's where a good weekend in the library helps out.  You *should*
know who the original manufacturer of the game is.  Go to the largest library
near you... and go look them up... Grab a copy of their D&B (Dunn and
Bradstreet[correct me if I'm wrong]), which will tell you their current
financial situation, assuming their a publicly-held company.

Next, I'd go look up on the CD-ROM database (for that's what's available here)
what copyrights, trademarks, patants, and other legal ownership they still
retain... this should be all inclusive, and include all of their filings
they've made with various federal offices.

Then... see if those copyrights/trademarks/patents are still in effect... I
don't remember what the law is, but I believe a patent is 7 years and a
copyright is 20 or so; and these of course can be extended.

This should tell you LOTS about this company and how their marks are legally
protected.  Patents/copyrights are considered a form of ownership, and the
original company could easily sue you if they still have a foot to stand on or
if they still exist.

Just like I said in my first posting... get a competent lawyer.  ;)

- -Neil
- --
*>  Neil Haldar                                                              <*
*>  [e-mail]                                        <*
*>  [e-mail]                                                      <*
*>  364 West Lane Ave #225, Cols., OH 43201   614.299.8529                   <*

+++++++++++++++++++++++++++

From: [e-mail] (rodney jacks)
Organization: Motorola Inc, Austin, Texas
Date: Fri, 30 Oct 1992 16:59:52 GMT

In article <[e-mail]> [e-mail] (Michael A. Kelly) writes:
>In article <[e-mail]> [e-mail] (Tim Smith) writes:
>>[e-mail] (Michael A. Kelly) writes:
>>
>>So you can't just say what you have done is "like the difference" between
>>Asteriods and Blasteroids.  Copyright protects expression of ideas, rather
>>than ideas themselves.  This means that if something is required to express
>>an idea, copyright can't protect it.  In particular, copyright can't
>>protect the idea of a "shoot rocks in space" game.  The court decided
>>that any "shoot rocks in space" game would include Asteroids, and so
>>there could be no copyright protection.
>>
>>On the other hand, "run around a maze avoiding enemies" is a broader
>>idea.  There is room for more variation in how that idea is expressed,
>>and K. C. Munchkin was too close to PAC-MAN.
>>
>>Note the result: a near exact clone of Asteroids was OK, but something that
>>had several differences from PAC-MAN wasn't OK.  I don't think you will be
>>able to get a good answer in your case without divulging details of your
>>game.
>
>OK.  The specific part of our game that we're worried about is:
>
>There is an enemy base/fortress/castle (hint hint)/mother ship which is
>surrounded by three concentric roughly circular (regular n-sided polygons)
>rings/shields.  The rings spin, with the outer and inner rings spinning the
>same direction and the middle ring spinning the opposite direction.  The
>good guy has to shoot out segments of the rings so that he has a clear
>shot at the enemy base when the holes in each ring line up.  The enemy base
>can shoot back, also only when the holes in the rings line up.  The base
>shoots huge plasma balls like in the first Star Trek movie.
>
>That is what is the same in both the original game and our game.  Here are
>some differences:
>
>In the original game, the base & rings were static in the center of the
>screen, and the good guy flew his ship around the base, with his flight
>wrapping around when he flew off the screen.  In our game, the base stays
>in one spot in the world/galaxy, but the galaxy is much bigger than the
>screen, so the base could be anywhere on the screen or not on the screen
>at all.  Here's one important difference between the two: there is no
>notion of the good guy's flight wrapping around on the screen.  The wrapping
>was very important in the original game; the enemy base could only shoot
>in the direction it was pointing, so the good guy could sit close to the edge
>of the screen and fire away from the castle (oops, I mean base), hitting
>it from behind, and then thrust forward a bit to the other side of the
>screen when the base was aiming at the ship, thus avoiding attack from the
>base while whaling on it.  There is no way to do that in our game.
>
>There are no bad guys in the original game (I think, although my partner
>thinks that there was).  There are quite a few in our game, with lots of
>variation in strength and strategy, plus 'yummies' and 'space garbage' and
>asteroids and such floating about in space.  And the good guy's ship is
>a lot more complicated than the original.
>
>We've basically taken a simple ten year old video game and extended it
>tremendously.  I consider the original game inspiration, but others may
>consider it more than that.  I don't want to get sued.  But I don't want
>to cause myself any unnecessary legal hassles either.  If it isn't possible
>for the makers of the original game to win a lawsuit against us, I'd
>rather not go out of my way to bring the game to their attention.
>
>So it sounds like our game vs. the original would probably go the way of
>K.C. Munchkin vs. PacMan.  What do you think?
>
>BTW, what happens if that company isn't around any more?
>
>Thanks for your help,
>
>Mike.
>--
>_____________________________________________________________________________
>Michael A. Kelly                                               Senior Partner
>[e-mail]                                      High Risk Ventures
>_____________________________________________________________________________

My guess is that as long as you don't copy the artwork or sounds from
Star Castle then you're probably safe.  You can probably use the basic
premise of the game safely.  But then I'm no lawyer :-)

- -Rodney
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (James Preston)
Date: 30 Oct 92 18:04:32 GMT
Organization: Amdahl Corporation, Sunnyvale CA

[e-mail] (Michael A. Kelly) writes:

}There are no bad guys in the original game (I think, although my partner
}thinks that there was).  There are quite a few in our game, with lots of
}variation in strength and strategy

If by "bad guys" you mean enemy ships other than the big mother, then there
definitely were bad guys in the original arcade game.  They took the form
of a swarm of little tiny "ships" that would start following your ship
around.

Are you planning on this being a commercial game or shareware?  In either
case, I look forward to it.  Be sure to let the mac newsgroups know when
it's released.

- --James Preston

+++++++++++++++++++++++++++

From: [e-mail] (Terry Carroll)
Date: 30 Oct 92 18:30:10 GMT
Organization: Amdahl Corporation

In article <[e-mail]>,
[e-mail] (Neil A Haldar) writes:
> Then... see if those copyrights/trademarks/patents are still in effect... I
> don't remember what the law is, but I believe a patent is 7 years and a
> copyright is 20 or so; and these of course can be extended.

A patent duration is 17 years, not subject to renewal (Although, I believe,
maintenence fees must be paid, or the patent lapses, which is similar in
effect to a shorter duration, with the maintenence fees serving to "renew"
for up to the full term of 17 years).  Sorry no cite available, this is from
memory, and if incorrect, I hope someone will post the correct information.

For works created after 1/1/1978, copyright is significantly longer than 20
years.  It is the life of the author plus 50 years for most works, and is 75
years for works made for hire, anonymous works, and pseudonymous works.
There is no longer any renewal.  17 USC 302.

For works created before 1/1/78, it's more complicated, but it effectively
works out to 75 years.  See 17 USC 303 and 304.

Terry Carroll - [e-mail] - 408/992-2152
The opinions presented above are not necessarily those of a sound mind.

+++++++++++++++++++++++++++

From: [e-mail] (Michael A. Kelly)
Organization: High Risk Ventures
Date: Fri, 30 Oct 1992 23:34:50 GMT

In article <[e-mail]> [e-mail] writes:
>
>Are you planning on this being a commercial game or shareware?

Sorry, I should I mentioned that in the first place.  It will commercial,
and will eventually be ported to the IBM and Amiga platforms.  That's why
I'm so concerned about getting sued.

Mike.
- --
_____________________________________________________________________________
Michael A. Kelly                                               Senior Partner
[e-mail]                                      High Risk Ventures
_____________________________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 30 Oct 92 18:48:42 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Neil A Haldar) writes:

>Then... see if those copyrights/trademarks/patents are still in effect... I
>don't remember what the law is, but I believe a patent is 7 years and a
>copyright is 20 or so; and these of course can be extended.

US Patents are 17 years ( 20 for foreign) and copyrights depending on who owns
the rights:


Author: Life of the author plus 50 years.

Corporation: 75 years.


>protected.  Patents/copyrights are considered a form of ownership, and the
>original company could easily sue you if they still have a foot to stand on
>if they still exist.


I believe that even if a company doesn't exist, someone or something still
owns the rights. Look at the name dbx. The company is no longer but many
other companies own rights to the name and its technologies.


Matt

- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Bruce Hayden)
Date: 1 Nov 92 07:29:07 GMT
Organization: Colorado SuperNet, Inc.

[e-mail] (Neil A Haldar) writes:

>Next, I'd go look up on the CD-ROM database (for that's what's available here)
>what copyrights, trademarks, patants, and other legal ownership they still
>retain... this should be all inclusive, and include all of their filings
>they've made with various federal offices.

>Then... see if those copyrights/trademarks/patents are still in effect... I
>don't remember what the law is, but I believe a patent is 7 years and a
>copyright is 20 or so; and these of course can be extended.

Utility patents have a term of upto 17 years (exercising all extensions).
Copyrights are now Life + 50 for individuals, or 75 years for corps, etc.
Renewals for older copyrights are going out the door (are becoming automatic).
Figure that if it was ever copyrighted, it probably still is. Also, note
that any work created after March 1, 1988 need not be marked to be protected.
Works between 1978 and 1988 may possibly still be protected w/o marking.
Registration with the C/R office is actually only required if and when
you are going to bring suit. So, all you will be able to see in the C/R
office files is if the C/R has been assigned. Otherwise, assume that it
is good.

>This should tell you LOTS about this company and how their marks are legally
>protected.  Patents/copyrights are considered a form of ownership, and the
>original company could easily sue you if they still have a foot to stand on or
>if they still exist.

Bruce E. Hayden
Copyrights, Patents, etc.
[phone]
[e-mail]
[e-mail]

---------------------------

From: [e-mail] (Michael Milligan)
Subject: How do I change the system font?
Date: 30 Oct 92 07:58:32 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

I'm trying to change the font used in the standard MDEF.  I wanna be able to
create a popup using Geneva 9.  Do I use the Script Manager for this?  Anybody
know how?

Michael
- --
- --------------------------------------------------------------------------------
- -  Michael Milligan, Jr                                    [e-mail] -
- -                                                                              -
- - "Behold, I stand at the door and knock. If anyone hears My voice and opens   -
- -  the door, I will come in to him and dine with him, and he with Me."         -
- -                                                              Revelation 3:20 -
- --------------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Mike Engber)
Date: 30 Oct 92 13:00:53 GMT
Organization: The Institute for the Learning Sciences

In article <[e-mail]> [e-mail] (Michael Milligan) writes:
>I'm trying to change the font used in the standard MDEF.  I wanna be able to
>create a popup using Geneva 9.  Do I use the Script Manager for this?  Anybody
>know how?

I'll take this opportunity to repost my soln w/ some minor bug fixes.
This is also covered in the Q&A stack, but they miss some fine points.

You should be able modify this to suit your needs.

- -ME

- --- written in THINK C ---

extern  short   SysFontFam  : 0x0BA6;
extern  short   SysFontSize : 0x0BA8;
extern  long    LastSpExtra : 0x0B4C;
extern  Ptr     CurFMInput  : 0x0988;


long PupSelect(MenuHandle theMenu,Point popPt,short popupItem,Boolean useWFont){
    short       item;
    short       itemMark;
    short       oldSysFont      = SysFontFam;
    short       oldSysSize      = SysFontSize;
    short       oldWMgrFont;
    short       oldWMgrSize;
    short       oldCWMgrFont;
    short       oldCWMgrSize;
    GrafPtr     curPort;
    GrafPtr     wMgrPort;
    CGrafPtr    wMgrCPort;
    SysEnvRec   theWorld;

    GetPort(&curPort);

    GetItemMark(theMenu,popupItem,&itemMark);

    /* no need to muck around if the current font is already the system font */
    if(curPort->txFont==SysFontFam && curPort->txSize==SysFontSize){
        useWFont = false;
    }

    if(useWFont){
        /* hack to fix bugs caused by programs that mess up the WindowMgr port(s) */
    /*  (e.g. MacWrite & Word)  - thanks to Leonard Rosenthal for soln */

        GetWMgrPort(&wMgrPort);
        SetPort(wMgrPort);
        oldWMgrFont = wMgrPort->txFont;
        oldWMgrSize = wMgrPort->txSize;
        TextFont(systemFont);
        TextSize(0);
        if(SysEnvirons(1,&theWorld) == noErr && theWorld.hasColorQD){
            GetCWMgrPort(&wMgrCPort);
            SetPort((GrafPtr)wMgrCPort);
            oldCWMgrFont = wMgrCPort->txFont;
            oldCWMgrSize = wMgrCPort->txSize;
            TextFont(systemFont);
            TextSize(0);
        }else{
            theWorld.hasColorQD = false;
        }
        SetPort(curPort);

        SysFontFam  = curPort->txFont;
        SysFontSize = curPort->txSize;
        LastSpExtra = -1L;
        CurFMInput  = (Ptr)(-1L);
        if(popupItem > 0){
            SetItemMark(theMenu,popupItem,'%'); <- char should be a bullet
        }
    }else{
        if(popupItem > 0){
            CheckItem(theMenu,popupItem,true);
        }
    }

    item = PopUpMenuSelect(theMenu,popPt.v,popPt.h,(popupItem>0) ? popupItem : 1);
    if(popupItem > 0){
        SetItemMark(theMenu,popupItem,itemMark);
    }

    if(useWFont){
        SetPort(wMgrPort);
        TextFont(oldWMgrFont);
        TextSize(oldWMgrSize);
        if(theWorld.hasColorQD){
            SetPort((GrafPtr)wMgrCPort);
            TextFont(oldCWMgrFont);
            TextSize(oldCWMgrSize);
        }
        SetPort(curPort);

        SysFontSize = oldSysSize;
        SysFontFam  = oldSysFont;
        LastSpExtra = -1L;
        CurFMInput  = (Ptr)-1L;
    }

    return item;
}

---------------------------

End of C.S.M.P. Digest
**********************